git 三路合并范例

master 拉起分支a、b、c

b更改代码合并入a

c更改代码合并入a

c在代码区域1更改代码合并入a

b不改区域1代码 再次合并入a

区域1代码使用哪个分支的？

1. 初始状态

假设你的操作顺序如下：

1. 从 master 拉出分支 a、b、c。

2. b 修改某个文件中的区域1代码，然后合并到 a（此时区域1代码变为 b 的版本）。

3. c 修改同一文件的区域1代码（可能不同内容），然后合并到 a（这时如果区域1和 b 修改的是相同位置，会产生冲突）。

4. 接着 b 再次合并到 a。

2. 关键：合并冲突解决记录

• 在步骤 3，当 c 合并到 a 时，如果区域1和 b 的修改重叠，Git 会提示冲突，你需要选择保留 c 的版本还是 b 的版本，或者手动修改。

  • 假设你选择了 保留 c 的版本（或者用 c 的修改解决冲突）。

• 那么合并完成后，a 分支的区域1代码现在是 c 的版本。

3. 步骤 4：b 再次合并到 a

• 这时 b 分支的该区域代码仍然是它自己第一次修改的那个版本（b 的版本）。

• a 分支已经是 c 的版本。

• 如果 b 从第一次合并到 master 之后，没有再改动区域1，那么 b 和 a 的共同祖先是它们上一次合并时的状态吗？
  其实这里要清楚：a 已经包含了 b 的第一个提交和 c 的提交。
  再次合并 b 到 a 时，Git 会比较：

  • 共同祖先：是 b 和 a 最后一次同步的点，可能是在第一次合并 b 到 a 时的那个版本（这时区域1是 b 的版本）。

  • a 的当前版本：区域1代码是 c 的版本。

  • b 的当前版本：区域1代码还是 b 的版本（假设 b 没再改）。

• 合并时，Git 会看到：

  • 祖先中：区域1 = b 版本

  • a 中：区域1 = c 版本

  • b 中：区域1 = b 版本

• 这意味着从祖先到 a，区域1被改成了 c 的版本；从祖先到 b，区域1没变（还是 b 版本）。

  这种情况下，Git 会直接采用 a 的版本，因为 b 相对祖先没有新的改动（b 的版本相对于祖先是相同内容），所以不会有冲突，也不会改变 a 的内容。

4. 结论

最终 a 分支的区域1代码仍然是 c 的版本，而不是 b 的版本，因为在第二次合并 b 时，b 在这个区域相对共同祖先没有新改动，所以不会覆盖 a 中已经更新的内容。

5. 如果 b 在第一次合并后又在区域1改了代码呢？

如果 b 在第一次合并到 a 之后，自己又提交了区域1的新修改，那么第二次合并 b 到 a 时，会触发冲突：

• 祖先（第一次合并时的 b 版本）

• a 的当前（c 版本）

• b 的当前（b 的新版本）

这时你需要解决冲突选择保留 a 还是 b 的版本。但根据你的描述，你没有提到 b 在第一次合并后又改了区域1，所以默认 b 没改，因此最终是 c 的版本。

git 共同祖先点的确定

共同祖先是两个分支最近的共同提交节点（分叉点之前最近的共同祖先）。

假设有分支 A 和 B：

「三年博客，如果觉得我的文章对您有用，请帮助本站成长」

赞(0) 打赏

支付宝

微信

赏 0

支付宝

微信